home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 233 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.4 KB

  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: bs@research.att.com (Bjarne Stroustrup)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Give operator. a chance
  5. Date: 1 Feb 1996 22:54:48 GMT
  6. Organization: ?
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <199602012239.PAA18361@ncar.ucar.EDU>
  9. NNTP-Posting-Host: taumet.eng.sun.com
  10. Content-Type: text
  11. Content-Length: 2105
  12. X-Lines: 66
  13. Originator: clamage@taumet
  14.  
  15.  
  16. Article 15876 of comp.std.c++:
  17. >From: jason@cygnus.com (Jason Merrill)
  18.  
  19.  > >>>>> Joe Buck <jbuck@Synopsys.COM> writes:
  20.  > 
  21.  > > Stroustrup proposes that operator. only forward to the resulting class
  22.  > > for a.m if the object itself doesn't have a member m.  I dislike that
  23.  > > approach; it is unnecessary since (&a)->m accesses it, and since
  24.  > > the class is going to present itself as a disguised reference object
  25.  > > in any case, only private code is going to mess around with the object's
  26.  > > own members.  In member functions, one would merely write "m".
  27.  
  28. I don't propose anything. I discuss a couple of alternatives in
  29. D&E sec11.5.2 (including the one Joe Buck states a preference for).
  30. I happen to weakly prefer the resolution Joe Buck refers to as mine,
  31. but my conclusion stands:
  32.  
  33.     ``The C++ community seems split over the issue of which
  34.     interpretation of operator.() is best.''
  35.  
  36.     ...
  37.  
  38.     ``there is no consensus on the importance of operator.()
  39.     either. Consequently, operator.() isn'r part of C++ and
  40.     the debate rage on.''
  41.  
  42. We did not have and we do not have the consensus necessary for
  43. inclusion in the standard and I do not know how to build one.
  44. The committee seriously considered operator.() on several occations
  45. over a couple of years. By now, the discussion is academic.
  46.  
  47.  > I think a more natural way to achieve the delegation semantics proposed by
  48.  > Stroustrup would be to extend 'using' along these lines:
  49.  > 
  50.  > struct A {
  51.  >   void f  ();
  52.  > };
  53.  > 
  54.  > struct ARef {
  55.  >   A* a;
  56.  >   using *a;
  57.  > };
  58.  > 
  59.  > main ()
  60.  > {
  61.  >   ARef ar = { new A };
  62.  >   ar.f (); // (*(ar.a)).f();
  63.  > }
  64.  > 
  65.  > Of course, that's not likely to happen either.
  66.  
  67. Exactly. However, I did think of that years ago, and tried it out
  68. (with a different syntax). The results of the experiment were strongly
  69. negative. See D&E sec 12.7.
  70.  
  71.     - Bjarne
  72.  > Jason
  73.  
  74. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  75.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  76.   summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  77. ]
  78.